Una transazione è una singola unità di lavoro

Le modifiche ai dati raramente arrivano da sole: un bonifico deve addebitare un conto e accreditare l'altro, e un ordine deve riservare scorte e registrare un pagamento. Se il sistema si interrompe a metà, il database finisce per descrivere un mondo che non è mai esistito. Una transazione è la risposta del database a questo problema — una sequenza di una o più operazioni che il database tratta come una singola e indivisibile unità di lavoro.

Tutto o niente

All'interno di una transazione, ogni operazione appartiene a un unico esito. Il database non espone mai uno stato finale in cui è avvenuta solo una parte della transazione. L'esempio classico è un bonifico tra due conti bancari: ridurre il saldo del conto di origine, poi aumentare il saldo del conto di destinazione. Se riuscisse solo il primo passo, il denaro svanirebbe; se riuscisse solo il secondo, il denaro comparirebbe dal nulla. Racchiudere entrambi i passi in una sola transazione elimina entrambe le possibilità.

Questa garanzia tutto-o-niente si chiama atomicità. Commit è l'atto che rende permanenti le modifiche della transazione; una transazione che non viene mai confermata non lascia alcuna traccia. Durabilità aggiunge il tassello finale: una volta che il commit è andato a buon fine, la modifica sopravvive anche se la macchina perde alimentazione un attimo dopo.

Una transazione è un confine

È utile immaginare una transazione come un confine tracciato attorno a un gruppo di istruzioni. Prima del confine e dopo di esso, i dati soddisfano le regole imposte dalla struttura. All'interno del confine esistono stati intermedi — un conto è già stato addebitato mentre l'altro non è ancora stato accreditato — ma questi stati sono privati della transazione. Le istruzioni successive in altre sessioni non li considerano come verità.

Due compiti insieme

Le transazioni svolgono quindi due compiti. Il primo è la gestione dei guasti: se il processo va in crash, la connessione cade o un'istruzione genera un errore, il database può ripristinare lo stato esistente prima dell'inizio della transazione. Il secondo è il controllo della visibilità: mentre il lavoro è in corso, gli altri lettori sono protetti dal risultato incompleto. Questi due compiti sono correlati ma non identici — l'atomicità decide se le modifiche vengono mantenute, mentre la visibilità è regolata dall'isolamento, l'impostazione che controlla quanto le transazioni concorrenti possono vedere l'una dell'altra.

Mantieni l'unità su una sola connessione

Lo stato della transazione appartiene a una connessione o sessione, quindi l'istruzione che apre la transazione e il commit che la conclude devono essere eseguiti sulla stessa connessione. Molti driver operano inoltre in modalità autocommit , in cui ogni singola istruzione è una transazione a sé — un'unità composta da più istruzioni richiede che l'autocommit sia disattivato o un avvio esplicito.

Una transazione è una singola unità di lavoro

Racchiudere entrambi i passi in una sola transazione elimina entrambe le possibilità. Concetti chiave: transazione — una sequenza di una o più operazioni eseguite come una singola e indivisibile unità di lavoro.

DOMANDA 1

Quale affermazione descrive meglio una transazione di database?

Una sequenza di una o più operazioni trattate come una singola e indivisibile unità di lavoro.

Un file di log che registra ogni istruzione mai eseguita dal database.

Una copia di backup del database effettuata prima di qualsiasi modifica.

Una singola istruzione SQL che modifica una riga.

DOMANDA 2

Un bonifico addebita il conto di origine e poi il server perde alimentazione prima che venga eseguito l'accredito. La transazione non è mai stata confermata. Cosa garantisce il database alla ripartenza?

Viene mantenuto solo l'addebito, perché è stato eseguito per primo.

L'addebito viene mantenuto e l'accredito viene riapplicato automaticamente.

Entrambe le modifiche vengono mantenute ma contrassegnate come incomplete.

Nessuna delle due modifiche sopravvive; la transazione incompleta viene annullata durante il ripristino.

DOMANDA 3

Qual è la differenza tra COMMIT e ROLLBACK?

Sono sinonimi; entrambi rendono permanenti le modifiche.

COMMIT termina l'istruzione corrente; ROLLBACK termina l'intera sessione.

COMMIT rende permanenti le modifiche della transazione; ROLLBACK le scarta e lascia i dati come erano prima dell'inizio della transazione.

COMMIT memorizza una copia dei dati; ROLLBACK ripristina quella copia.

DOMANDA 4

Uno sviluppatore afferma: "Poiché il mio bonifico viene eseguito all'interno di una sola transazione, nessun'altra sessione può vedere l'addebito prima dell'accredito". È corretto?

No, perché le altre sessioni possono sempre vedere i dati non confermati in ogni database.

No; l'atomicità decide se le modifiche vengono mantenute, mentre la visibilità è regolata dall'isolamento, quindi un'altra sessione potrebbe comunque leggere valori non confermati a seconda del livello di isolamento.

Sì; l'atomicità nasconde ogni stato intermedio da tutte le altre sessioni.

Sì, ma solo se la transazione viene mantenuta molto breve.

DOMANDA 5

Un commit va a buon fine e la macchina perde alimentazione un attimo dopo. Cosa garantisce il database dopo il ripristino?

Le modifiche confermate sono ancora presenti, perché la durabilità garantisce che le modifiche confermate sopravvivano a crash e riavvii.

Sopravvive solo l'ultima istruzione della transazione.

La transazione viene annullata automaticamente dopo il riavvio.

Le modifiche vanno perse perché l'interruzione di corrente è avvenuta prima del checkpoint successivo.

Caso di studio: il bonifico interrotto

Leggi lo scenario seguente e rispondi alle due domande.

Un'applicazione trasferisce 100 dal conto 1 al conto 2. Esegue START TRANSACTION, poi UPDATE accounts SET balance = balance - 100 WHERE id = 1. Prima che il secondo UPDATE possa essere eseguito, la connessione di rete al database cade e il processo dell'applicazione va in crash. La tabella accounts ha un vincolo di controllo che mantiene i saldi non negativi. Quando l'applicazione si riavvia, apre una nuova connessione e non trova alcuna traccia del completamento del bonifico, e i saldi su entrambi i conti appaiono esattamente come prima del tentativo.

Dal punto di vista del database, cosa succede all'addebito e quale garanzia lo spiega?

Risposta:
L'addebito non diventa mai un risultato finale perché la transazione non è mai stata confermata. Una transazione è una singola unità di lavoro, e l'atomicità significa che l'intera unità viene applicata o nessuna parte di essa. Quando la connessione termina, il database annulla la transazione — o esegue lo stesso annullamento durante il ripristino dopo un crash — riportando lo stato esistente prima dell'inizio della transazione. Non esiste quindi alcuno stato in cui 100 ha lasciato il conto 1 senza arrivare al conto 2, così nessun denaro scompare.

In seguito l'applicazione viene rifattorizzata per utilizzare un pool di connessioni. Perché il primo UPDATE e il commit devono essere eseguiti sulla stessa connessione o sessione, e quale ruolo svolge l'autocommit?

Risposta:
Lo stato della transazione appartiene a una connessione o sessione, quindi l'istruzione che apre la transazione e il commit che la conclude devono essere emessi sulla stessa connessione. Se un livello di pooling indirizza le istruzioni successive a una connessione diversa, il commit si applica a un'unità di lavoro diversa e la transazione originale rimane aperta o viene annullata alla disconnessione, il che infrange il confine previsto dall'applicazione. L'autocommit è importante perché la maggior parte dei driver opera in modalità autocommit per impostazione predefinita, in cui ogni istruzione è una transazione a sé; in quella modalità l'addebito diventerebbe permanente nel momento stesso in cui viene eseguito e non esisterebbe alcuna unità tutto-o-niente. Un'unità composta da più istruzioni richiede quindi che l'autocommit sia disattivato o un avvio esplicito della transazione.